Split out []byte-array generation for core-library namespaces #345
Conversation
This eliminates the need to hand-maintain the declaration of the []byte arrays, allowing `gen_data.go` to generate those declarations and initialization (statically, in a func init(), or in a lazily-called function) as it sees fit.
Strangely, the original approach (initializing within `func init()`) makes the test suite run seconds faster on my AMD Ryzen 3 (running Ubuntu), and I suspect the same will be the case on my MacBook Pro (another amd64).
Not sure... I am not even sure it's worth creating a separate file for those functions...Granted |
|
I guess |
Actually, it's excluded when building/running I think I prefer the name |
|
I saw that it's excluded in |
"Conflicts" was the wrong word, actually. Since This might seem a bit strange for now, but I've got another PR following it up that removes all but the references to the linter |
|
Ah, that makes sense. Thanks! |
This eliminates the need to hand-maintain the declaration of the
[]bytearrays, allowinggen_data.goto automatically generate those declarations and initialization (statically, in a func init(), or in a lazily-called function) as it sees fit.internalLibswould be empty forgen_data, but that seems appropriate, and it works fine.Something like this might be a next step towards addressing #326 and/or #344.
(
data.gomight be a better name thanprocs_data.go?)